This PR improves a couple issues with our YAML/JSON marshaling logic, which I noticed when implementing #120.

In particular, the util.SerializeToYAML function previously had an omitNull bool parameter (which was kind of poorly named imo), which would cause it to serialize the results first to JSON, then back into a Go type, and then to YAML. The purpose was to ensure we correctly marshal structs from third-party libraries or generated code that are missing yaml: struct tags, but have json: struct tags (in particular, the omitempty tag, which causes null/empty values to be omitted). However, we were setting the omitNull parameter to true in all but a couple of cases, which meant that the vast majority of our yaml: struct tags were actually being ignored, and were therefore completely unnecessary. It also created a weird footgun, where it you forgot to set omitNull to true, you could end up with YAML output that differed significantly from the corresponding JSON output. I therefore decided to remove the omitNull parameter, make the function always roundtrip to/from JSON first, and get rid of all the yaml: struct tags. This should ensure that our YAML output is always 1:1 with our JSON output (even for third-party or generated structs that only have json: tags) and remove any confusion with regards to the yaml: tags.

One of the only cases where we were setting omitNull to false was when marshaling the config struct for the sake of tiger config show. As a result, the version_check_interval field was being marshaled differently in the JSON vs YAML output. In the JSON output, it was being marshaled as an integer containing nanoseconds (because time.Duration is an int64 under the hood), whereas in the YAML output, it was marshaled using the time.Duration.String() format (due to how gopkg.in/yaml.v3 marshals time.Duration values). Changing the behavior of SerializeToYAML to always roundtrip to/from JSON caused it to use the integer representation everywhere, but I actually think the string representation is the one we want (that's how it's represented in the config file itself, for example, because viper has special handling for durations). I therefore added a special util.Duration type that allows durations to be marshaled to JSON using time.Duration.String(), which make it use the string representation everywhere (i.e. in both the tiger config show -o json and tiger config show -o yaml output).